fix(core): reject x-mcp-header on number-typed parameters - #2762
Draft
pcarleton wants to merge 1 commit into
Draft
fix(core): reject x-mcp-header on number-typed parameters#2762pcarleton wants to merge 1 commit into
pcarleton wants to merge 1 commit into
Conversation
The 2026-07-28 Streamable HTTP spec permits x-mcp-header only on integer, string and boolean parameters and requires clients to exclude tools that violate this. 'number' was allow-listed solely to pass an older conformance fixture that used number-typed header parameters; that fixture was corrected (modelcontextprotocol/conformance#371) and the conformance suite is about to add a negative case for it (modelcontextprotocol/conformance#444). Co-Authored-By: Claude <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: e0e7b4b The changes in this PR will be included in the next version bump. This PR includes changesets to release 6 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
@modelcontextprotocol/client
@modelcontextprotocol/codemod
@modelcontextprotocol/core
@modelcontextprotocol/server
@modelcontextprotocol/server-legacy
@modelcontextprotocol/express
@modelcontextprotocol/fastify
@modelcontextprotocol/hono
@modelcontextprotocol/node
commit: |
JosephDoUrden
left a comment
JosephDoUrden
left a comment
Contributor
There was a problem hiding this comment.
Pulled e0e7b4b, 2817 passing across core-internal, client and server, typecheck and lint ok. Put 'number' back and only the new test fails. Conformance at the pinned alpha.11, 2026-07-28 legs, 385/385 client and 151/151 server.
One nit, mcpParamHeaders.ts:383 still checks decl.type === 'number', nothing reaches it now.
Looks merge-ready to me.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation and Context
The 2026-07-28 Streamable HTTP spec restricts
x-mcp-headerto primitive parameters, "MUST only be applied to parameters with primitive types (integer, string, boolean). Parameters with typenumberare not permitted", and requires clients to "reject tool definitions where anyx-mcp-headervalue violates these constraints" by excluding the tool fromtools/list.PERMITTED_X_MCP_HEADER_TYPESincore-internalstill allow-listed'number'. The comment on it explains why: an older conformance fixture shippedtype: "number"header parameters and expected clients to mirror them. That fixture was corrected in modelcontextprotocol/conformance#371 (the release this repo pins already usesinteger), and modelcontextprotocol/conformance#444 adds the negative case, anumber-typedx-mcp-headertool that a conforming client must drop, under the existingsep-2243-x-mcp-header-primitive-onlycheck in the scoredhttp-invalid-tool-headersscenario. With'number'still permitted, this SDK would keep and call that tool and report a failure there once the conformance pin moves past 0.2.0-alpha.11. The python, go, csharp and rust SDKs already rejectnumber.What changed
packages/core-internal/src/shared/mcpParamHeaders.ts: drop'number'fromPERMITTED_X_MCP_HEADER_TYPES; replace the stale comment.packages/core-internal/test/shared/mcpParamHeaders.test.ts: add "number-typed property is rejected" alongside the object/array/null cases.The numeric comparison paths in
validateMcpParamHeaders/mcpParamPrimitiveToStringare untouched (they still serveinteger).How Has This Been Tested?
pnpm exec vitest runforcore-internal/test/shared/mcpParamHeaders.test.ts(61 passed),client/test/client/mcpParamMirroring.test.ts(18),server/test/server/mcpParamValidation.test.ts(7);pnpm typecheck+pnpm lintin core-internal; pre-push build/typecheck/lint hooks green.Breaking Changes
A tool whose
inputSchemaputsx-mcp-headeron atype: "number"property is now treated as an invalid declaration (client: excluded fromlistTools(); server: registration rejected), as the spec requires. Usetype: "integer"for numeric header parameters.Types of changes
Checklist